User-Centred Requirements Handbook |
Storyboards (also termed "Presentation Scenarios" by Nielsen) are sequences of images which demonstrate the relationship between individual events (e.g. screen outputs) and actions within a system. A typical storyboard will contain a number of images depicting features such as menus, dialogue boxes and windows. The formation of these screen representations into a sequence conveys further information regarding the possible structures, functionality and navigation options available. The storyboard can be shown to colleagues in a design team as well as potential users, allowing others to visualise the composition and scope of possible interfaces and offer critical feedback.
Few technical resources are required to create a storyboard. Simple drawing tools (both computer and non computer-based) are sufficient. Storyboards provide a platform for exploring user requirements options via a static representation which can be shown to both potential users and members of a design team. This can result in the selection and refinement of requirements.
Benefits
• Feedback can be gained on system functionality, style and also navigation options early on in the development cycle where changes can be more easily implemented.
• The method promotes communication between designers and users.
• Storyboards can be created quickly and easily.
• Only minimal resources and materials are required.
• The technique can be utilised by those with little or no human factors expertise.
Limitations
• Storyboards can lack the interactive quality of other prototyping methods although interactive storyboarding systems are available. Madsen & Aiken (1993), for instance, report the use of an interactive HyperCard based system.
• Because of their simplicity, storyboards do not support the evaluation of fine design detail.
• Storyboards do not accurately convey system response times.
What you need
The technical resources required to create storyboards are minimal, and include drawing tools (both computer and non computer-based), paper, card, pens and adhesives. Furthermore, the time and human resources are low.
Process
1. Give consideration to the scenarios of use which the storyboard will reflect. A storyboard may represent several activities such as entering, saving or printing information. Alternatively a separate storyboard may be created to represent each distinct theme.
2. Construct the storyboard as a sequence of screen representations, using separate images to reflect changes in system appearance. Thus the storyboard will indicate the availability and purpose of dialogue windows, menu items, toolbars and icons.
3. The elements of a storyboard can be annotated with explanatory captions to aid audience understanding and evaluation.
4. The completed storyboard can be shown to design teams as well as intended users to solicit evaluative feedback. Several storyboards can be created and shown to an audience in order to explore different requirements options.
5. It may be useful to video or audio record the feedback sessions for later review or to show to other colleagues.
6. Further storyboards can be created and evaluated in light of feedback.
Practical guidelines
• Produce high level drawings to represent the system. Details on drawings may distract the users or side-track the discussion.
• It may not be necessary to produce many drawings covering every stage of the interaction. Using a single drawing as a basis it is possible to discuss the events taking place before and afterwards.
• Try to include higher level organisational aspects in the drawings (e.g. interactions between people) rather than just showing user interactions with the system interface. This will give the users a fuller picture of the system concept and allow them to foresee socio-technical mismatches.
Further information
Madsen and Aiken (1993), Nielsen (1991) and Preece (1994).